home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 561 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.3 KB
  1. From: itschere@techfak.uni-bielefeld.de
  2. Subject: Re: pipes & ptys
  3. Date: Wed, 20 Oct 93 1:39:45 MET
  4.  
  5. Juergen Lock
  6. > 
  7. > > Well, what else can I do in a Program like a window manager, if I've
  8. > > got to look for every char?
  9. > 
  10. >  well Eric said that already but in different words... :)  a 1k RAW
  11. > read() does not block until it has read 1k, only until _some_ data is
  12. > available. (pty master reads are always RAW)  if it receives 200 bytes
  13. > (i.e. pty slave write()s 200 bytes) it returns 200 bytes, if data comes
  14. > in 1-byte-at-a-time it reads 1 byte, or whatever has accumulated in the
  15. > buffer (pipe) since the last read.
  16. > 
  17. >  so look at each char does not mean you need one system call for each
  18. > char...
  19.  
  20. Ok, got this, but: (see my other mail) it will return as soon as ther is
  21. some data, say, when it get's its next time slice, which is 16ms long on
  22. my 60Hz TT-VBL, right? Now I estimate that the writer (if really (worst case,
  23. of course, but that's what counts.)) using 1 bytes I/O, doesn't manage
  24. to output more than something like 30 chars per timeslice, so 60 slices
  25. a 30 bytes (always completely ignoring the time I need to read the data),~
  26. makes 1800 CPS, and that looks like the number I've measured.
  27.  
  28. > >   Point is that system calling overhead is soooo big that it doesn't matter
  29. > > a lot if the pipefs has got to do 1 or 4 bytes read.
  30. > 
  31. >  yes but it doesn't... have to do single-char IO.  and when you have
  32. > larger read/writes this character shuffling can cause overhead of
  33. > n times the size of the actual device IO.
  34.  
  35. Perhaps we can start a personal dispute about this, but so far I heavily
  36. doubt this. Sorry, no proofs so far... :-(
  37.  
  38. > type            read    write    speed (CPS)    % CPU load (top)
  39. > -----------------------------------------------------------
  40. > pipe            4096    4096    270000
  41. > pty            4096    4096    a bit less
  42. > 
  43. >  pty output would get nearly as fast as the pipe, and serial ports could
  44. > run full speed and no longer eat up all available cycles...
  45.  
  46. If a) you really use big chunks and b) modems are operated by interrupt...
  47.  
  48. > >  At least at my setup the involved device
  49. > > drivers can easily be fixed.
  50. > 
  51. >  hmm how do you mean that?
  52.  
  53. Well, to make the biosfs drives expect char pointers instead longs. None
  54. of my program _seems_ to complain about this. But obviously that's no
  55. compatible solution... ;-)
  56.  
  57. [other stuff deleted, 'cause it's clear to me now]
  58.  
  59. bye,
  60. TeSche
  61.  
  62.  
  63.